#AWScean 「開発者にTwilioとAWSを知ってもらおう勉強会」でIoTの基礎を話してきた。@大阪

こんにちは、せーのです。

ということで、大阪に行ってTwilioJP-UG大阪＆AWScean合同勉強会「開発者にTwilioとAWSを知ってもらおう勉強会」に参加してきました。

スライド

使用したスライドです。

テーマ

今回はタイトルからAWSにはそんなに関わっていない開発者を対象としてIoTを業務で使うモチベーションやそのツールとしてのAWS IoTをご紹介してきました。

こんな感じの構成にしたのはいくつか理由がありました。まずIoTはバズワードとして言葉はだいぶ認知されているものの、何かグッとした盛り上がりに欠けてるのではないか、という思いがありました。AWSで言えばLambdaやAPI Gatewayのような花形になると思っていたAWS IoTがイマイチぱっとこない。これってHowがわからないのではなくてWhyが見えないのではないか、と。つまり「どのようにしてAWS IoTを使うのか」ではなくて「そもそもIoTをなぜ使うのか」という部分を細く噛み砕くことでIoTに対する関心が生まれるのではないか、という想定で座学の部分を長くしてみました。

基本的に私のセッションは余り業務には直結しないパフォーマンス的なものが多いです。その最たるものがこの間のDevelopers.io 2016でのクロージングセッションですね。笑

このように身につけた技術をおおよそ役に立たない方面につぎ込むことが好きだったりするのですが、最近少しずつですが「ためになるセッション」をやっても盛り上げることができるスキルを磨くのも大事なのではないか、と思うようになり、今回はあえておふざけ要素の一切ない構成にしました。
わかりやすく言うならでんじろう先生から池上彰へ、という感じです。

※スカパラで例えるならオーセンティックスカのテンポを東京風にアレンジした妖しさ満点の初期スカパラから現在のJ-Popや歌謡曲の要素を上手く取り入れてメジャー的に垢抜けた「Tokyo Ska」の確立に至る分岐点となった楽曲「花ふぶき」のような立ち位置です。ギョギョギョ。

やってみて

思っていたよりIoTを触ったことがある参加者の方が多かったのが意外でした。もう少し突っ込んだ内容のものを用意した方が良かったかな、と。
慣れない真面目な話題でセッションを進めていたので会場の無音に耐えられずにトークでおふざけ方面に逃げてしまうことも少しありましたが、概ね言いたいことは伝わったかな、と感じています。

補足

30分のセッションでは伝えきれないと思い省いた部分をここですこし補足しておきたいと思います。

Device GatewayへのPublishは冪等性を確保した設計をしよう

AWS IoTのMQTT BrokerはQoS0及びQoS1しか対応していません（Soracom Beamを使用するとQoS0のみになります）。これはつまりデータが確実にBrokerに届いた、という保証がなかったり、データが重複して届く可能性がある、という事を指します。特にデータが重複して届く場合には、それによってRules Engine以降の処理に影響が出ないようにする必要があります。それをデバイス側で制御するのはCPUや電池を想定以上に食ってしまうことになるので、クラウド側で処理するようにしましょう。ベストは特に処理をしなくても同じデータは上書きするような冪等性のある設計です。リクエストには個々にIDが振られているのでRules Engineでそれを拾って格納時につけておくような設計を検討してみてください。

ログは必ず出そう。ただ分量には注意。

IoTデータは特にトレースしにくいですので、おかしなデータが入ってくるような時にその原因はどこにあるのか、各場所でログを吐いておくことが重要です。 デバイスのログはあるととても便利ですがデバイス内に確保しておくとあっという間にフルストレージになってしまうので注意が必要です。クラウドとの接続がWi-Fiなどの特に通信状態を気にしなくていいような強固なものであれば、5分に1回くらいのペースでS3に投げてしまう + ローテートする、というような実装ができますが、3G通信など帯域に制限のある場合は実際にクラウドに送った生データをログとしてAWS IoT側でS3に分岐、保管しておくだけでも充分良いことかと思います。

AWS IoTのログはこちらの記事を参考にしてください。

AWS IoTのログをCloudWatch Logsで取得する #reinvent

Lambdaのログは自動的にCloudWatch Logsに入っていますのでConsole.log()コマンドで必要なデバッグログを吐いておくといいでしょう。

ただ、IoTデータは1分に100-200レコードになることも多く、自動で作られたSQL全文など細かいログを１レコードごとに吐いているとログデータが膨大になり、その保管でコストがかさむ、ということもあります。
開発時のデバッグログは必ず見直し、本番投入時には運用に必要な最低限のログに落としておきましょう。

AWS IoT Device SDKは使いどころに注意

IoTデバイスとAWS IoTを繋げるのに便利なのはAWS IoT Device SDKを使用することです。ただこのSDKはAWS IoTの全ての機能を網羅した作りのため、デバイス側の要件によってはややファットになる場合があります。
IoTデバイス側は特に電池や通信を考えてシンプルに実装するのがいいです。ですので例えばセンサーデータを拾って投げるだけならmosquittoやmqtt.jsの使用を検討してみる、通信にSoracomを使うのであれば証明書類はSoracom側にセットしてしまう、等IoTデバイス側をなるべくシンプルにするような工夫をしてみましょう。

まとめ

今後のAWS IoTはMQTT over WebSocketをどうやって実践に持ち込むか(やっぱりWebアプリ => AWS IoT => Device Shadow => IoTデバイス、かなあ）等、色々考えるネタが豊富でまだまだやることがたくさんあります。 大阪は刺激の多い場所でした。とても楽しかったです。

次回大阪に来る時は新喜劇がすっちー座長の時を狙って行きたいと思います。